Skip to content

Conversation

@pbergeron-adsk
Copy link
Contributor

@pbergeron-adsk pbergeron-adsk commented Nov 21, 2025

Linked issues

SG-40934

Summarize your change.

Using -pyeval to load movies stopped setting the Display Transfer Function to sRGB, leaving it at "None". This occurred because RV creates an RVOutputGroup node in command-line mode instead of RVDisplayGroup, and the Python code only checked for RVDisplayGroup nodes.

It was only later when the UI started (and after the data had been loaded) that actual RVDisplayGroups got created, but they weren't being configured.

I'm not sure how this ever worked in 2021.3 (it was in the days before OpenRV), but this fix seems to do the trick.

The fix:

  • (1) modified the code to handle both RVOutputGroup and RVDisplayGroup node types, and ;
  • (2) immediately configure any new RVDisplayGroups when they're created after the UI starts.

Now the Display Transfer Function on the RVDisplayGroup is set to sRGB in all scenarios.

See below image for a full explanation of what happened.

image

Describe the reason for the change.

RVDisplayGroup's transfer function was not being set properly.

Describe what you have tested and on which operating system.

macOS

Add a list of changes, and note any that might need special attention during the review.

If possible, provide screenshots.

@pbergeron-adsk pbergeron-adsk marked this pull request as ready for review November 21, 2025 18:56
@pbergeron-adsk pbergeron-adsk changed the title Fix 40934: displaygroup sRGB not being set when loading media via pyeval Fix 40934: RVDisplayGroup's transfer function not being set to sRGB when loading media via pyeval Nov 21, 2025
self._haveNewDisplayGroups = True
# BUGFIX: When a new RVDisplayGroup is created AFTER initial setup
# (e.g., when UI starts after -pyeval), configure it immediately
self.setDisplayFromProfile()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't this interfere with the ocio_source_setup.py if OCIO mode is enabled ?

Copy link
Contributor

@bernie-laberge bernie-laberge Nov 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be safer to move the pyeval further down the line where we know that the RVDisplayGroup has been properly initialized.
Like here for example:

# BUGFIX: Also handle RVOutputGroup in addition to RVDisplayGroup
# When RV is run in command-line mode (e.g., via -pyeval), it uses RVOutputGroup
# instead of RVDisplayGroup for the default display output
if (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would really like to know what changed which led to this regression. I'll do some research in the original RV git repo and report back.

@bernie-laberge
Copy link
Contributor

bernie-laberge commented Nov 26, 2025

FYI: Status report of my investigation to figure out the source of this regression:
As confirmed by @savoiei , this appears to be a regression originating from RV 2022.0.0 because RV 2021.1.0 does not have this issue.
But RV 7.7.1 does have the issue !
I was wondering Why. So I compared the code from RV 2022.0.0 and RV 2021.1.0 and check what I found:
In RV 2022.0.0, progressive source loading was disabled by default!
And in RV 7.7.1, there was no progressive source loading.
I tested it and it does work in the latest RV if you enable progressive source loading:
export RV_PROGRESSIVE_SOURCE_LOADING=1

Which makes sense because with progressive source loading, the source-group-complete is delayed long enough so that the RVDisplayGroup gets created. Without progressive source loading, the pyeval gets executed before the creation of RVDisplayGroup so the code in source_setup.py has no chance to be executed properly thus the bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants